Let mouse wheel zoom snap to view resolution levels - #7210

Up to standards ✅

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

I will try to check if i just made a setup error. You are on MacOS? Are you using mousewheel or touchpad?

I will try to check if i just made a setup error. You are on MacOS? Are you using mouswheel or touchpad?

I am using the mouse wheel, @oliver-stoehr is probably using the touchpad, I guess.

Yes, I'm using macOS with touchpad.

Hmm, both of you can confirm an improvement, so this is strange. I am on Ubuntu Linux and what makes the difference there is setting to zoomFactor: 1.3 independent of the browser. It would be interesting to see what happens on Windows. Would it maybe be an option to do both settings? Or maybe @thomaslow or @henning-gerhardt can test what happens on their systems.

I know that Firefox at least has an option called "Use smooth scrolling". I had disabled this as I want a fast scrolling. Maybe this setting has some kind of influence. I can try this changes tomorrow.

Would it maybe be an option to do both settings?

I think that's a good idea to cover all bases. I will add both settings and check whether it has any adverse effects on how the zoom feature works for me. Maybe you can do the same for your setup and confirm that it works for you, too.

There seems to be some device specific stuff going on, especially in OpenLayers version 6 which we are appearantly using:
openlayers/openlayers#15423

Setting it to to 1.2 is already good enough for me

compared to main (1.1)

Setting it to to 1.2 is already good enough for me

And that is with setting constrainResolution as well?

Setting it to to 1.2 is already good enough for me

And that is with setting constrainResolution as well?

Yes, constrainResolution has no visible effect for me, but i suppose it is important what happens on Windows. I will try to set those things on our production systems and let my colleagues test in Windows.

Edit:
i have to correct myself. When adding constrainResolution (in combination with zoom 1.2) things seem even faster

Changing only constrainResolution has no visible effect over main as far as i can see:

Edit: Given the evidence from only my machine i would vote for zoomFactor: 1.2 and constrainResolution: true.

For me, zooming is a bit slow in the current main branch, but still usable. I would call it "precise". It is definitely way faster than @solth video. It looks to be the same as @BartChris video. Increasing zoomFactor to 1.2 would be an improvement for my devices (Fedora, Windows, Firefox, Chrome with basic Logitech Mouse).

Looking at the documentation of OpenLayers, the purpose of the setting constrainResolution: true is to enable auto-zooming to the closest pre-defined resolution level (or zoom level). When setting it to true, we should also specify a list of predefined resolutions. I guess, by default, if none are provided, some reasonable resolutions are auto-calculated somehow, which is why zooming may be different for some people (or not) with this setting (jumping from one auto-calculated resolution level to the next).

I think adjusting the zoomFactor would be better. Given that there are many different devices out there, maybe this can be a user setting in the future, e.g. with a interactive slider ranging from 1.05 to 1.5? Then, everybody can decide on their own.

Up to standards ✅

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

I think adjusting the zoomFactor would be better. Given that there are many different devices out there, maybe this can be a user setting in the future, e.g. with a interactive slider ranging from 1.05 to 1.5? Then, everybody can decide on their own.

Sounds like a good plan for the future. But I take it that you don't opose merging the current pull request as it is as a first step then? This could also be backported to 3.9.x and 4.0.x, while adding a new setting to the individual metadata editor configuration (which I support in general!) is something that would require a database migration and thus would not be eligible for a backport, and could therefor be added to the next major version (e.g. 4.1.0, for example)

But I take it that you don't opose merging the current pull request

I am not opposed. Hopefully, this PR should improve things. Apparently, my system is not really affected by this. Both zoomFactor 1.1 and 1.2 work fine for me. One is a bit faster than the other. With contrainResolution: true zooming is even faster, but still perfectly fine. Personally I would prefer 1.2 with contrainResolution: false (see below). But I guess, maybe, there are other systems where this change is perceived by users as making things worse, I don't know.

One additional observation: In Windows, there is a setting at "Einstellungen -> Bluetooth und Geräte -> Maus -> Zeilen, die gleichzeitig gescrollt werden sollen" which controls how fast pages are scrolled with a mouse wheel. With constrainResolution: true, it does not matter whether you choose 1 (minimum) or 100 (maximum). The zoom behavior in OpenLayers is the same. With constrainResolution: false, this setting also influences the zoom speed. Again, this could be an advantage or disadvantage for some users, depending on their preferences.

Personally I would prefer 1.2 with contrainResolution: false (see below). But I guess, maybe, there are other systems where this change is perceived by users as making things worse, I don't know.

Leaving constrainResolution: false results in a larger zoomFactor having next to no effect at all for me, so I am going to merge this pull request with both settings adjusted. It should be an improvement on the current situtation for most users and can be the start of further, incremental enhancements.

I tried this current changes and there are no big differences for me. It is maybe a little bit faster but no big difference. I did not use this feature very often - until this pull request only once or twice, so my impression could be wrong.